Historically, in industrial controllers, in particular in 16-Bit fieldbus controllers, data was transferred between a first and second data storage unit by simply copying bits stored in known memory locations. For example, for user-specific industrial control programs stored somewhere, e.g., in a flash memory, data was transferred by a so called “MEMCOPY” command, which operated to copy data from a source location into a target location, e.g., a defined memory location in random access memory (RAM) of the industrial controller.
The data transfer operation may occur, for example, when starting and booting the industrial controller to enable the industrial controller to execute instructions provided in the user-specific industrial control program. This procedure of directly transferring data between memory address locations can be performed, for example, by “LOAD FILE” and “READ FILE” commands of a management software having control over the industrial controller. When booting the industrial controller after executing the “MEMCOPY” command, the industrial control program is copied from the flash memory to the industrial controller's RAM, and the industrial control program is then executed from RAM.
Historically, operating systems including file system services have also been available, particularly for industrial controllers making use of standard operating systems such as DOS, Windows and the like. By providing an access layer in form of an access file (e.g., “syslib*.lib” or “syslibfile.lib” file), the user-specific industrial control program could make use of the file system services provided by the operating system. In this manner, the user-specific industrial control program executed on the industrial controller could more flexibly handle data via the file system services. Use of file system services was also available with so called “open controllers” with 16-Bit fieldbus controllers and later also for 32-Bit fieldbus controllers (FBC).
Due to the fact that the user-specific industrial control program can make use of file system services, there is no need to administrate specific address locations and to have knowledge of specific physical address locations on storage units. It is sufficient to define a command that is independent from a specific hardware platform, such as a file open command that uses a dedicated filename, and to read and write data into this file by use of file system service commands. The physical handling of the data is managed by the file system service of the operating system. This reduces the burden on the programmer of a user-specific control program as the programmer does not need to consider details of a specific hardware platform or define data management on the hardware platform. By making file system services accessible through a file system access layer, the user-specific industrial control program, via the file system services, can handle data with regard to storage units on a more abstract level. This enables the user-specific industrial control program, for example, to log data into files, to log changes of data into files (e.g., creating trend files), and to read data from files for use in the industrial control process (e.g., to make use of recipe files and respective recipe data stored therein).
A problem with conventional methods for handling files in an industrial controller via file system services of an operating system is the complexity of the software. More specifically, a user may need to utilize header files and code files to enable the user to define an industrial control program that uses system services of the operating system. In addition, the industrial control program needs to be adapted to a specific hardware platform in order to execute system services of the operating system.